System and method of pre-establishing ssl session connections for faster ssl connection establishment

ABSTRACT

A secure session pre-handshake establishment module facilitates a secure session connection request between an appliance and a server associated with a website. The facilitation causes the appliance to receive session information. At least one session to one or more servers listed in a server group is reused if the session information corresponding to the secure session connection request has been cached. Secure session connections between the appliance and servers listed in the server group are formed if the session information corresponding to the secure session connection request has not been cached to pre-establish one or more SSL connections so that when one or more SSL connection requests are received, the one or more pre-established SSL connections can be used without performing full SSL handshake procedures.

RELATED APPLICATIONS

This application is a continuation of Ser. No. 15/010,692 filed Jan. 29,2016, which is hereby incorporated herein in its entirety by reference.

BACKGROUND

A middlebox is a network appliance that manipulates Internet traffic byoptimizing data flow across the network. Middleboxes can be configuredas wide area network (“WAN”) optimizers and can be deployed in pairsacross two geographically separated locations to optimize data trafficbetween the two middleboxes. Middleboxes can be connected through asingle link or multiple links such as a leased line link and a broadbandlink. Middleboxes, which may be called WAN optimizers, can work as apair of devices with primary job of optimizing the network traffic,providing better user experience.

For high availability networks, it is common to establish secureconnections between two end point entities, for example between a clientdevice and a web server. One or more middleboxes can be deployed betweenthe two end point entities. Middleboxes can proxy one or more secureconnections by monitoring secure connections on a first link between oneend point entity and a middlebox and forming a new secure connectionbetween the middlebox and the other end point entity based on the firstlink.

In a typical Secure Socket Layer/Transport Layer Security (SSL/TLS)connection between a client and a server, a single web session to aserver can create multiple SSL/TLS connections to a server. Also when aweb page gets refreshed, multiple secure connections are created to aserver. In the environment where multiple SSL/TLS connections to theserver are proxied by a cluster of middleboxes, each of the connectionscan be proxied by a different middlebox from the cluster. Based oncurrent technology, each of the middleboxes in the cluster would have toestablish an SSL full handshake with the server to obtain certificatesand to compute necessary keys for establishing a secure connection.

The problem is that, more often than not, a single connection request tothe server associated with a single website is ensued by a series ofuser requests to other related websites and lead to multiple SSL sessionconnections to different servers with different fully qualified domainnames To establish these connections, the middlebox has to establish anSSL full handshake with each of the server and other related servers toobtain a certificate and compute necessary security keys to establish asecure channel This task is, however, highly CPU intensive and mightinvolve an additional Round Trip Time (RTT) and additional data to fetchthe certificate chain.

SUMMARY

An appliance of pre-establishing Secure Socket Layer (SSL) sessionconnections for SSL connection establishment is provided. The applianceincludes a secure session pre-handshake establishment module configuredto facilitate a secure session connection request between an applianceand a server associated with a website, with the secure sessionconnection request including a name of the server associated with thewebsite, and wherein the facilitation causes the appliance to receivesession information.

The secure session pre-handshake establishment module reuses at leastone session to one or more servers listed in a server group if thesession information corresponding to the secure session connectionrequest has been cached. The secure session pre-handshake establishmentmodule forms secure session connections between the appliance andservers listed in the server group if the session informationcorresponding to the secure session connection request has not beencached to pre-establish one or more SSL connections so that when one ormore SSL connection requests are received. The one or morepre-established SSL connections can be used without performing full SSLhandshake procedures.

The secure session pre-handshake establishment module may be furtherconfigured to identify the server group based on information of theserver associated with the website in the secure session connectionrequest.

The names of the servers listed in the server group may comprise a headserver name and a plurality of sub-servers names. A head serverrepresents at least one webpage and comprises a plurality of objectsprovided by the plurality of sub-servers to load completely the at leastone webpage.

The secure session pre-handshake establishment module may be furtherconfigured to determine whether there is a matching server among thehead server name and the plurality of sub-servers names in the servergroup, with the matching server matching to the server associated withthe website.

The secure session pre-handshake establishment module may be furtherconfigured to increase a frequency count of the matching server based onthe determination that there is a matching server.

The session information may comprise at least one of session identifierand session ticket information. The session information is acquiredbased on a SSL/Transport Layer Security (TLS) full handshake protocol.

The secure session pre-handshake establishment module may be furtherconfigured to accumulate the session connection request and subsequentsession connection requests for a predetermined time period, based onthe determination that session information corresponding to the sessionconnection request and the subsequent session connection requests hasnot been cached. A determination is made whether there are one or morematching servers in the server group matching to the session connectionrequest and the subsequent session connection requests. A frequencycount of each of the one or more matching servers is updated based onthe determination that there are the one or more matching servers.

The secure session pre-handshake establishment module may be furtherconfigured to add or delete at least one server from the server groupbased on a number of the frequency count.

The secure session pre-handshake establishment module may be furtherconfigured to accumulate SSL connections made by a client device for apredetermined time period, and determine a list of one or more servernames belonging to the server group based on the accumulated SSLconnections.

Another aspect is directed to a method of pre-establishing Secure SocketLayer (SSL) session connections for SSL connection establishment. Themethod comprises facilitating a secure session connection requestbetween an appliance and a server associated with a website, with thesecure session connection request including a name of the serverassociated with the website. The facilitation causes the appliance toreceive session information.

At least one session to one or more servers listed in a server group isreused if the session information corresponding to the secure sessionconnection request has been cached. Secure session connections areformed between the appliance and servers listed in the server group ifthe session information corresponding to the secure session connectionrequest has not been cached to pre-establish one or more SSL connectionsso that when one or more SSL connection requests are received, the oneor more pre-established SSL connections can be used without performingfull SSL handshake procedures.

Yet another aspect is directed to a non-transitory computer readablestorage medium that stores a set of instructions that are executable byat least one processor of an appliance to cause the appliance to performa method of pre-establishing Secure Socket Layer (SSL) sessionconnections for SSL connection establishment. The method performed is asdescribed above.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings showing exampleembodiments of this disclosure. In the drawings:

FIG. 1 is a block diagram of an exemplary network environment,consistent with embodiments of the present disclosure.

FIGS. 2A-2B are block diagrams of an exemplary computing device,consistent with embodiments of the present disclosure.

FIG. 3 is a block diagram of an exemplary appliance illustrated in FIG.1, consistent with embodiments of the present disclosure.

FIG. 4 is a block diagram of an exemplary protocol stack of appliance,consistent with embodiments of the present disclosure.

FIG. 5 is a block diagram of an exemplary network environment,consistent with embodiments of the present disclosure.

FIG. 6 is a flowchart representing an exemplary method ofpre-establishing SSL session connections for faster SSL connectionestablishment, consistent with embodiments of the present disclosure.

FIG. 7 is a flowchart representing an exemplary method of forming aserver group, consistent with embodiments of the present disclosure.

FIG. 8 is a flowchart representing an exemplary method of refining aserver group, consistent with embodiments of the present disclosure.

FIG. 9 is an exemplary data structure providing a server group for aclient device, consistent with embodiments of the present disclosure.

DETAILED DESCRIPTION

Reference will now be made in detail to the exemplary embodimentsimplemented according to the present description, the examples of whichare illustrated in the accompanying drawings. Wherever possible, thesame reference numbers will be used throughout the drawings to refer tothe same or like parts.

The embodiments described herein provide improved efficiency of secureconnections in a network. The efficient secure connections can berealized by proxying a secure connection between one middlebox deviceand a server, e.g., a web server, via SSL/TLS full handshake procedure,and using server group information containing a head server name andsub-servers names associated with the head server name and sessioninformation, frequency count information, etc. This can improveefficiency of SSL/TLS connections without necessarily performing SSL/TLSfull handshake procedures whenever receiving a new session connectionrequest to the same server. Moreover, the embodiments described hereincan be less CPU intensive and can use less Round Trip Time (RTT) andless data to fetch the certificate chain in computing session keys.

FIG. 1 is a block diagram of an exemplary network environment 100. Whileexemplary network environment 100 is directed to a virtual networkenvironment, it is appreciated that the network environment can be anytype of network that communicates using packets. Network environment 100can include one or more client devices 102, public network 104, gateway106, an appliance 108, a private network 110, a data center 120, abranch office 140, and a public server 150.

One or more client devices 102 are devices that can acquire remoteservices from data center 120 through various means. Client devices 102can communicate with data center 120 either directly (e.g., clientdevice 102F) or indirectly through public network 104 (e.g., clientdevices 102A-D) or private network 110 (e.g., client device 102E). Whenclient device 102 communicates through public network 104 or privatenetwork 110, a communication link can be established. For example, alink can be established by public network 104, gateway 106, andappliance 108, thereby providing a client device (e.g. client devices102A-D) access to data center 120. A link can also be established bybranch office 140 including appliance 108′, private network 110, andappliance 108, thereby providing a client device (e.g. client device102E) access to data center 120. While client devices 102 are portrayedas a computer (e.g., client devices 102A, 102E, and 102F), a laptop(e.g., client device 102B), a tablet (e.g., client device 102C), and amobile smart phone (e.g., client device 102D), it is appreciated thatclient device 102 could be any type of device (e.g., wearable or smartwatch) that communicates packets to and from data center 120.

Public network 104 and private network 110 can be any type of networksuch as a wide area network (WAN), a local area network (LAN), or ametropolitan area network (MAN). As an example, a WAN can be theInternet or the World Wide Web, and a LAN can be a corporate Intranet.Public network 104 and private network 110 can be a wired network or awireless network.

Gateway 106 is a physical device or is software that is part of aphysical device that interfaces between two networks having differentprotocols. Gateway 106, for example, can be a server, a router, a host,or a proxy server. In some embodiments, gateway 106 can include or becoupled to a firewall separating gateway 106 from public network 104(e.g., Internet). Gateway has the ability to modify signals receivedfrom client device 102 into signals that appliance 108 and/or datacenter 120 can understand and vice versa.

Appliance 108 is a device that optimizes wide area network (WAN) trafficby including, for example, a quality of service (“QoS”) engine. In someembodiments, appliance 108 optimizes other types of network traffic,such as local area network (LAN) traffic, metropolitan area network(MAN) traffic, or wireless network traffic. Appliance 108 can optimizenetwork traffic by, for example, scheduling data packets in anestablished communication link so that the data packets can betransmitted or dropped at a scheduled time and rate. In someembodiments, appliance 108 is a physical device, such as Citrix System'sByteMobile™, Netscaler™, or CloudBridge™. In some embodiments, appliance108 can be a virtual appliance. In some embodiments, appliance can be aphysical device having multiple instances of virtual machines (e.g.,virtual Branch Repeater). A first appliance (e.g., appliance 108) canwork in conjunction with or in cooperation with a second appliance(e.g., appliance 108′) to optimize network traffic. For example, thefirst appliance can be located between the WAN and a corporate LAN(e.g., data center 120), while the second appliance can be locatedbetween branch office (e.g., branch office 140) and a WAN connection. Insome embodiments, the functionality of gateway 106 and appliance 108 canbe located in a single physical device. Moreover, in some embodiments,appliance 108 and gateway 106 can be part of the same device. Appliances108 and 108′ can be functionally the same or similar. Appliance 108 isfurther described below corresponding to FIG. 3.

Data center 120 is a central repository, either physical or virtual, forthe storage, management, and dissemination of data and informationpertaining to a particular public or private entity. Data center 120 canbe used to house computer systems and associated components, such as oneor more physical servers, virtual servers, and storage systems. Datacenter 120 can include, among other things, one or more servers (e.g.,enterprise server 122) and a backend system 130. In some embodimentsdata center 120 can include gateway 106, one or more appliances 108, ora combination of both.

Enterprise server 122 is an entity represented by an IP address and canexist as a single entity or a member of a server farm. Enterprise server122 can be a physical server or a virtual server. In some embodiments,enterprise server 122 can include a hardware layer, an operating system,and a hypervisor creating or managing one or more virtual machines.Enterprise server 122 provides one or more services to an endpoint.These services include providing one or more applications 128 to one ormore endpoints (e.g., client devices 102A-F or branch office 140). Forexample, applications 128 can include Microsoft Windows™-basedapplications and computing resources.

Desktop delivery controller 124 is a device that enables delivery ofservices, such as virtual desktops 126 to client devices 102A-F orbranch office 140. Desktop delivery controller 124 providesfunctionality required to manage, maintain, and optimize all virtualdesktop communications.

In some embodiments, the services include providing one or more virtualdesktops 126 that can provide one or more applications 128. Virtualdesktops 126 can include hosted shared desktops, allowing multiple usersto access a single shared Remote Desktop Services desktop, virtualdesktop infrastructure desktops allowing each user to have their ownvirtual machine, streaming disk images, a local virtual machine,individual applications (e.g., one or more applications 128), or acombination thereof.

Backend system 130 is a single or multiple instances of computernetworking hardware, appliances, or servers in a server farm or a bankof servers and interfaces directly or indirectly with enterprise server122. For example, backend system 130 can include Microsoft ActiveDirectory™, which can provide a number of network services, includinglightweight directory access protocol (LDAP) directory services,Kerberos-based authentication, domain name system (DNS)-based naming andother network information, and synchronization of directory updatesamongst several servers. Backend system 130 can also include, amongother things, an Oracle™ backend server, a SQL Server backend, and/or adynamic host configuration protocol (DHCP). Backend system 130 canprovide data, services, or a combination of both to data center 120,which can then provide that information via varying forms to clientdevices 102 or branch office 140.

Branch office 140 is part of a local area network (LAN) that is part ofthe Wireless LAN (WLAN) having data center 120. Branch office 140 caninclude, among other things, appliance 108′ and remote backend 142. Insome embodiments, appliance 108′ can sit between branch office 140 andprivate network 110. As stated above, appliance 108′ can work withappliance 108. Remote backend 142 can be set up in similar manner asbackend system 130 of data center 120. Client device 102E can be locatedon-site to branch office 140 or can be located remotely from branchoffice 140.

Public server 150 is an entity represented by an IP address. Publicserver 150 can be a physical server or a virtual server. In someembodiments, public server 150 can include a hardware layer, anoperating system, and a security agent issuing security-relatedparameters such as public keys, cipher certificates, session identifiersand session tickets, and managing one or more secure connections. Publicserver 150 can be accessed directly or indirectly by client devices102A-F. Public server 150 provides one or more services to an endpoint.These services include one or more applications, such as web-browserapplications, to one or more endpoints (e.g., client devices 102A-F,data center 120, or branch office 140). Public server 150 can providesecure connections using Internet security protocols, e.g., SSL/TLSprotocols, for secure services to one or more endpoints (e.g., clientdevices 102A-F, data center 120, or branch office 140). The presentapplication describes improved efficiency of SSL/TLS connections byproxying connections between a middlebox and another middlebox or publicserver 150. However, it is appreciated that the disclosed method can beapplicable on any kind between two apparatuses to improve efficiency ofSSL/TLS connections.

Appliances 108 and 108′ and gateway 106 can be deployed as or executedon any type and form of specific computing device (e.g., such as thecomputing device of FIGS. 2A-2B) capable of communicating on any typeand form of network described herein. Appliances 108 and 108′ can bedeployed individually or as a pair operatively connected together.

As shown in FIGS. 2A-2B, each computing device 200 includes a centralprocessing unit (CPU) 221 and a main memory 222. CPU 221 can be anylogic circuitry that responds to and processes instructions fetched fromthe main memory 222. CPU 221 can be a single or multiplemicroprocessors, field-programmable gate arrays (FPGAs), or digitalsignal processors (DSPs) capable of executing particular sets ofinstructions stored in a memory (e.g., main memory 222) or cache (e.g.,cache 240). The memory includes a tangible and/or non-transitorycomputer-readable medium, such as a flexible disk, a hard disk, a CD-ROM(compact disk read-only memory), MO (magneto-optical) drive, a DVD-ROM(digital versatile disk read-only memory), a DVD-RAM (digital versatiledisk random-access memory), flash drive, flash memory, registers,caches, or a semiconductor memory. Main memory 222 can be one or morememory chips capable of storing data and allowing any storage locationto be directly accessed by CPU 221. Main memory 222 can be any type ofrandom access memory (RAM), or any other available memory chip capableof operating as described herein. In the exemplary embodiment shown inFIG. 2A, CPU 221 communicates with main memory 222 via a system bus 250.Computing device 200 can also include a visual display device 224 and aninput/output (I/O) device 230 (e.g., a keyboard, mouse, or pointingdevice) connected through I/O controller 223, both of which communicatevia system bus 250. One of ordinary skill in the art would appreciatethat CPU 221 can also communicate with main memory 222 and other devicesin manners other than through system bus 250, such as through serialcommunication manners or point-to-point communication manners.Furthermore, I/O device 230 can also provide storage and/or aninstallation medium for the computing device 200.

FIG. 2B depicts an embodiment of an exemplary computing device 200 inwhich CPU 221 communicates directly with main memory 222 via a memoryport 203. CPU 221 can communicate with a cache 240 via a secondary bus(not shown), sometimes referred to as a backside bus. In some otherembodiments, CPU 221 can communicate with cache 240 via system bus 250.Cache 240 typically has a faster response time than main memory 222. Insome embodiments, such as the embodiment shown in FIG. 2B, CPU 221 cancommunicate directly with I/O device 230 via an I/O port (not shown). Infurther embodiments, I/O device 230 can be a bridge 270 between systembus 250 and an external communication bus, such as a USB bus, an AppleDesktop Bus, an RS-232 serial connection, a SCSI bus, a FireWire™ bus, aFireWire 800™ bus, an Ethernet bus, an AppleTalk™ bus, a GigabitEthernet bus, an Asynchronous Transfer Mode bus, a HIPPI bus, a SuperHIPPI bus, a SerialPlus bus, a SCI/LAMP bus, a FibreChannel™ bus, or aSerial Attached small computer system interface bus, or some other typeof data bus.

As shown in FIG. 2A, computing device 200 can support any suitableinstallation device 216, such as a disk drive or other input port forreceiving one or more computer-readable media such as, for example, aUSB device, flash drive, SD memory card; a hard-drive; or any otherdevice suitable for installing software and programs such as any clientagent 220, or portion thereof. Computing device 200 can further comprisea storage device 228, such as one or more hard disk drives or redundantarrays of independent disks, for storing an operating system and otherrelated software, and for storing application software programs such asany program related to client agent 220. Optionally, any of theinstallation devices 216 could also be used as storage device 228.

Furthermore, computing device 200 can include a network interface 218 tointerface to a LAN, WAN, MAN, or the Internet through a variety of linksincluding, but not limited to, standard telephone lines, LAN or WANlinks (e.g., 802.11, T1, T3, 56 kb, X.25), broadband links (e.g., ISDN,Frame Relay, ATM), wireless connections (Wi-Fi, Bluetooth, Z-Wave,Zigbee), or some combination of any or all of the above. Networkinterface 218 can comprise a built-in network adapter, network interfacecard, PCMCIA network card, card bus network adapter, wireless networkadapter, USB network adapter, modem or any other device suitable forinterfacing computing device 200 to any type of network capable ofcommunication and performing the operations described herein.

FIG. 3 is a block diagram of an exemplary appliance 108 and/or 108′illustrated in FIG. 1, consistent with embodiments of the presentdisclosure. Appliance 108 can include an SSL session exchange module322, an SSL pre-handshake establishment module 342, and one or morenetwork interfaces 218A-N consistent with network interface 218 of FIG.2A. Although FIG. 3 depicts network interfaces 218A-218N as two networkinterfaces, it is appreciated that interfaces 218A-218N can include anynumber of network interfaces.

SSL session exchange module 322 is a module, which is a packagedfunctional hardware unit designed for use with other components or apart of a program that performs a particular function of relatedfunctions. In some aspects, SSL session exchange module 322 can operateon two or more devices, for example, in branch office 140 or at datacenter 120, and public server 150, functionally connected to providemore efficient SSL/TLS connections. Each device having SSL sessionexchange module 322 can be configured to perform SSL full handshakeprocedure to make a secure session connection between client devices 102and appliance 108 or 108′, and between appliance 108 or 108′ and apublic server 150.

SSL pre-handshake establishment module 342 is a module for providingmore efficient pre-establishment of SSL/TLS session connections forfaster SSL connections. In some aspects, SSL pre-handshake establishmentmodule 342 can operate on two or more devices, for example, in branchoffice 140 or at data center 120, and public server 150, functionallyconnected to provide this functionality. Each device having SSLpre-handshake establishment module 342 can be configured to facilitate asecure session connection between a client device and a serverassociated with a website, wherein the facilitation causes the applianceto receive session information, determine whether session informationcorresponding to the secure session connection request has been cached,determine whether the server is associated with a server group based onthe determination that session information has not been cached, and formsecure session connections between the client device and servers listedin the server group based on the determination that the server isassociated with a server group. SSL pre-handshake establishment module342 can be configured to identify a server group based on information ofthe server associated with the website in the secure session connectionrequest. The secure session connection request can include a name of theserver associated with the website in a server name indicator (SNI)field of a data packet (e.g., Client Hello packet). The name of theserver in a server name indicator field can be matched to a head servername, as shown in FIG. 9. The servers listed in the server groupcomprise a head server name and a plurality of sub-servers names, a headserver representing at least one webpage and comprising a plurality ofobjects provided by the plurality of sub-servers to load completely theat least one webpage. SSL pre-handshake establishment module 342 canalso be configured to determine whether there is a matching server amongthe head server name and the plurality of sub-servers names in theserver group, the matching server matching to the server associated withthe website. SSL pre-handshake establishment module 342 can also beconfigured to increase a frequency count of the matching server based onthe determination that there is a matching server. SSL pre-handshakeestablishment module 342 can also be configured to reuse at least onesession to one or more servers listed in the server group, for example,by forming a shorten SSL/TLS handshake in accordance with InternetEngineering Task Force (IETF) Request For Comments (RFC) 5077, based onthe determination that session information corresponding to the securesession connection request has been cached. The session informationcomprises at least one of session identifier and session ticketinformation that can be acquired based on a SSL/Transport Layer Security(TLS) full handshake protocol. SSL pre-handshake establishment module342 can further be configured to accumulate the session connectionrequest and subsequent session connection requests for a predeterminedtime period, based on the determination that session informationcorresponding to the session connection request and the subsequentsession connection requests has not been cached, determine whether thereare one or more matching servers in the server group matching to thesession connection request and the subsequent session connectionrequests, update a frequency count of each of the one or more matchingservers based on the determination that there are the one or morematching servers, and add or delete at least one server from the servergroup based on a number of the frequency count.

FIG. 4 is a block diagram of an exemplary protocol stack 400 ofappliance 108 and/or 108′, consistent with embodiments of the presentdisclosure. According to some embodiments, appliance 108 and/or 108′ canbe configured to have a security layer, e.g., SSL/TLS layer 430. TheSSL/TLS layer 430 can include SSL session exchange module 322 (depictedin FIG. 3) and a secure socket Application Programming Interface (API)(not shown). The security layer, e.g., SSL/TLS layer 430 of FIG. 4, canuse underlying layers for reliable communications. Such underlyinglayers can be provided by, e.g., Transport Control Protocol (TCP) layer420 and Internet Protocol (IP) layer 410. Applications, such as webservice applications, can use the secure socket API to encryptcommunication with any remote application that communicates according toSSL/TLS protocol. Any standard Internet web browser on public server 150can be accessed by secure web server applications using applicationprotocols such as HyperText Transfer Protocol (HTTP) 440, File TransferProtocol (FTP) 450, Simple Mail Transfer Protocol (SMTP) 460, etc. ontop of SSL/TLS 430.

In some embodiments, SSL/TLS layer 430 can include a record protocollayer 431, a handshake protocol layer 432, cipher change protocol layer433, and alert protocol layer 434, as referenced in IETF RFC 6101. Therecord protocol layer 431 can receive uninterpreted data from higherlayers, e.g., application layer. The record protocol layer 431 isresponsible for fragmenting uninterpreted data with fixed length andencrypting packets that were broken down with fixed-length compressingthe data. The record protocol layer 431 is also responsible for addingSSL header in the packets.

The handshake protocol layer 432 that operates on top of the recordprotocol layer 431 can produce cryptographic parameters of sessionstate. As an example, primary SSL session exchange module 322A thatoperates in application 108A can act as an SSL client, and public server150 can act as an SSL server. When an SSL client and an SSL server firststart communicating, the SSL client and the SSL server agree on aprotocol version, select cryptographic algorithms, optionallyauthenticate each other, and use public key encryption techniques togenerate shared secrets. These processes are performed in the handshakeprotocol, which can be summarized as follows: the SSL client sends aclient hello message to which the SSL server must respond with a serverhello message, or else a fatal error will occur and the connection willfail. The SSL client hello and SSL server hello are used to establishsecurity enhancement capabilities between the SSL client and the SSLserver. The client hello and server hello establish the followingattributes: Protocol Version, Session ID, Cipher Suite, and CompressionMethod. Additionally, two random values are generated and exchanged:ClientHello.random and ServerHello.random.

The cipher change protocol layer 433 is to signal transitions inciphering strategies between the SSL client and the SSL server. In otherwords, sending (from the SSL client to the SSL server or vice versa) amessage to notify that subsequent records are to be protected underjust-negotiated CipherSpec and keys.

The alert protocol layer 434 supports alert messages to convey severityof a message and a description of an alert. An alert can include, forexample, closure alerts and error alerts. Closure alerts are used tonotify that a connection is ending in order to avoid a truncationattack. Error alerts are used to send an error message in the event oferror detections. Upon transmission or receipt of a fatal alert message,both the SSL client and the SSL server immediately close a connection.

FIG. 5 is a block diagram of an exemplary network environment 500,consistent with embodiments of the present disclosure. It is appreciatedthat network environment 500 is a simplified illustration and that othercomponents can be added in network environment 500 whenever necessary.Also, network environment 500 can be any type of network thatcommunicates using packets. The network environment 500 can include aplurality of client devices 102 (e.g., 102B and 102E depicted in FIG.5), appliance 108′ coupled to branch office 140, appliance 108 that maybe located in or out of data center 120, and a plurality of publicservers 150 depicted in FIG. 1 and sub-servers 160A-160C depicted inFIG. 5). Although a single appliance 108′ is shown in branch office 140in FIG. 5, it is appreciated that one or more appliances 108′ can belocated in a plurality of branch offices 140. Likewise, although asingle appliance 108 is shown in data center 120 in FIG. 5, it isappreciated that one or more appliances 108 can be associated with datacenter 120.

Network environment 500 can have a plurality of SSL/TLS connections attwo or more stages between client device 102 and public server 150. Asan example, there can be, at a first stage, a single session 560comprising three SSL/TLS connections 502A-502C between client devices102 (e.g., 102B) and appliance 108, the SSL/TLS connections betweenwhich refers to SSL1 510. In some embodiments, SSL1 510 can also haveanother single session 570 comprising three SSL/TLS connections501A-501C between client device 102 (e.g., 102E) and appliance 108′ inbranch office 140, and three other SSL/TLS connections 503A-503C betweenappliance 108′ in branch office 140 and appliance 108.

One or more client devices 102 can directly connect to appliance 108, orindirectly connect to appliance 108 via appliance 108′ in branch office140. For example, client device 102B is directly connected to appliance108, and client device 102E is indirectly connected to appliances 108via appliance 108′ in branch office 140.

At a second stage, there can be other SSL/TLS connections (e.g., 530,531, 540, 541, 550 and 551) between appliance 108 and one or more publicservers 150 depicted in FIG. 1 and sub-servers 160A-160C depicted inFIG. 5, those SSL/TLS connections between which refer to SSL2 520.

The embodiments described herein address the SSL2 520 connections at thesecond stage for assisting with establishing a faster SSL connection bypre-establishing SSL session connections with one or more servers toload at least one complete webpage whose objects are embedded on the oneor more servers. In exemplary embodiments, after receiving from a clientdevice an SSL session connection request to a public server 150associated with a website, appliance 108 can perform SSL/TLS fullhandshake procedures with the public server 150 associated with thewebsite. The website can comprise a plurality of webpage objects to format least one complete webpage. Some webpage objects can be embedded onone or more other servers. In the present disclosure, the one or moreother servers are hereafter called sub-servers 160A-160C. The publicserver 150 associated with the website can provide appliance 108 withinformation about sub-servers 160A-160C. Then, using this information,appliance 108 can perform SSL/TLS full handshake procedures (e.g., 530,540, and 550) with each of the sub-servers 160A-160C. Appliance 108 canacquire session information such as session identifier and/or sessionticket information via SSL/TLS full handshake procedures. Such sessioninformation can be used to reuse at least one session connection (e.g.,551) to the server associated with the website and/or each of thesub-servers 160A-160C. Alternatively, appliance 108 can pre-establish atleast one SSL session connection to the server associated with thewebsite and/or each of the sub-servers 160A-160C, which is described inthe following FIG. 6.

FIG. 6 is a flowchart representing an exemplary method 600 ofpre-establishing SSL session connections for faster SSL connectionestablishment, consistent with embodiments of the present disclosure. Itwill be readily appreciated that the illustrated procedure can bealtered to delete steps or further include additional steps. Whilemethod 600 is described as being performed by appliance 108, it isappreciated that other components can be added or omitted and the method600 can be performed by other devices alone (e.g., appliance 108′) or incombination with appliance 108.

As an initial start, appliance 108 receives from a client device 102(either directly or via an appliance at a branch office (e.g., appliance108′)) a secure session connection request to a server associated with awebsite at step 610. The secure session connection request can be an SSLsession connection request. Appliance 108 also facilitates the securesession connection request between client device 102 and a serverassociated with a website, wherein the facilitation causes the applianceto receive session information at this step 610.

In exemplary embodiments, upon receipt of the secure session connectionrequest from client device 102, appliance 108 can further forward thesecure session connection request to the server associated with thewebsite. Based on that request, appliance can 108 can receive from theserver a list of sub-servers identifiers associated with the server,each sub-server having one or more objects required to form a webpage ofthe website. Appliance 108 can also receive, from the server, sessioninformation of each of the sub-servers.

In some embodiments, upon receipt of the secure session connectionrequest from client device 102, appliance 108 can further access one ormore data structures storing a server group having a server name, aplurality of sub-servers names associated with the server name, andsession information of the server and each of sub-servers associatedwith the server. The server group can include other information which isused to facilitate a secure session connection request between clientdevice and a server associated with a website.

Appliance 108 also determines whether session information correspondingto the secure session connection request has been cached at step 620.Session information can be obtained via SSL/TLS full handshakeprocedure. SSL/TLS full handshake procedure includes procedure disclosedin IETF RFC 6101. Session information can include session identifier orsession ticket information. A session identifier is an arbitrary bytesequence chosen by a server to identify an active or resumable sessionstate. Obtaining one or more session identifiers via SSL/TLS fullhandshake procedure is disclosed in IETF RFC 5246. A session ticketcontaining encrypted session state information is created by a TLSserver (e.g., public server 150) and sent to a TLS client (e.g.,appliance 108). TLS client can present the session ticket to the TLSserver to resume a session. Obtaining one or more session tickets viaSSL/TLS full handshake procedure is disclosed in IETF RFC 5077.

When session information corresponding to the secure session connectionrequest has been cached, it means that the server can be associated witha server group at this step 620 or has been already associated with aserver group before the step 620. Data structure providing a servergroup can be maintained per a client device 102 and is described in FIG.9 in detail. When determining that the session information correspondingto the secure session connection request has been cached, appliance 108reuses at least one session to one or more servers listed in the servergroup at step 630.

When determining that the session information corresponding to thesecure session connection request has not been cached, appliance 108determines whether the server is associated with a server group at step640. When determining that the server is associated with a server group,appliance 108 further forms secure session connections between theappliance and servers listed in the server group at step 650. Thisformation assists with pre-establishing one or more SSL connections.Thus, whenever receiving one or more SSL connection requests in thefuture the one or more pre-established SSL connections can be usedwithout necessarily performing full SSL handshake procedures, which inturn saves one RTT and computational intensive task for new securesession connections and enhances user experience.

FIG. 7 is a flowchart representing an exemplary method 700 of forming aserver group, consistent with embodiments of the present disclosure. Itwill be readily appreciated that the illustrated procedure can bealtered to delete steps or further include additional steps. Whilemethod 700 is described as being performed by an appliance 108, it isappreciated that other components can be added or omitted and the method700 can be performed by other devices alone (e.g., appliance 108′) or incombination with appliance 108.

At step 710, Appliance 108 facilitates a secure session connectionrequest between client device 102 and a server associated with awebsite, wherein the facilitation causes the appliance to receivesession information at step 710. The secure session connection requestcan be an SSL session connection request.

In some embodiments, upon receipt of the secure session connectionrequest from client device 102, appliance 108 can further access one ormore data structures storing a server group having a server name, aplurality of sub-servers names associated with the server name, andsession information of the server and each of sub-servers associatedwith the server. The server group can include other information which isused to facilitate a secure session connection request between clientdevice and a server associated with a website.

Appliance 108 also determines whether session information correspondingto the plurality of secure session connection requests has been cachedat step 720. As described above, session information can include sessionidentifier or session ticket information which can be obtained viaSSL/TLS full handshake procedure based on IETF RFC 5246 or IETF RFC5077, respectively.

When determining that session information corresponding to the pluralityof secure session connection requests has not been cached, appliance 108also accumulates one or more secure session connection requests for apredetermined time period at step 730. For example, appliance 108receives 10 secure connection requests from a client device for 0.5seconds and determines that session information corresponding to 7secure connection requests among 10 received secure connection requestshas not been cached. Then, appliance 108 accumulates 7 secure connectionrequests to form a server group. Appliance 108 can configure apredetermined time period how long to accumulate one or more securesession connection requests.

At step 740, appliance 108 further forms a server group based on the oneor more accumulated secure session connection requests whose sessioninformation has not been cached. Appliance 108 forms a server groupincluding, for example as shown in FIG. 9, a head server name 1030A,frequency count of the head server name 1031A, list of sub-server names1040A, frequency count of each of the sub-server names 1042A-1042C,session-related parameter 1050A, and timeout 1060A. Appliance 108 canperform full SSL handshake procedures to acquire session information ofthe head server and the sub-server listed in the server group. Appliance108 can terminate pre-established connections at expiry of timeout1060A. Appliance 108 can also store the server group information in amemory locally in the appliance 108 or externally connected to a networkdatabase.

Referring now to FIG. 8, a flowchart representing an exemplary method800 of refining a server group, consistent with embodiments of thepresent disclosure. It will be readily appreciated that the illustratedprocedure can be altered to delete steps or further include additionalsteps. While method 800 is described as being performed by appliance108, it is appreciated that other components can be added or omitted andthe method 800 can be performed by other devices alone (e.g., appliance108′) or in combination with appliance 108.

At step 810, appliance 108 receives from a client device 102 a securesession connection request to a server associated with a website at step810. Appliance 108 identifies a server group based on information of theserver associated with the website in the secure connection request atstep 820. For example, appliance 108 can search a server group to see ifthere is a server name in the server group which matches to a servername associated with a website in the secure session connection request.When finding the same server name in the server group, appliance 108 canidentify the server group affiliated with the server associated with thewebsite in the secure connection request.

Appliance 108 accumulates one or more secure session connection requestsfor a predetermined time period whose session information has not beencached at step 830. For example, appliance 108 receives 10 secureconnection requests from a client device for 0.5 seconds and determinesthat session information corresponding to 7 secure connection requestsamong 10 received secure connection requests has not been cached. Then,appliance 108 accumulates 7 secure connection requests to use refining aserver group. Appliance 108 can configure a predetermined time periodhow long to accumulate one or more secure session connection requests.

At step 840, appliance 108 determines whether there are one or morematching servers in a server group matching to any of the one or moreaccumulated secure session connection requests. When determining thatthere are one or more matching servers in the server group, appliance108 updates a frequency count of each of the one or more matchingservers in the server group at step 850. In exemplary embodiments, whendetermining that a server name in secure session connection requestsmatches to a server name in a server group three times and assuming thata current frequency count value be 2, appliance 108 updates frequencycount of the server to 5.

Appliance 108 further adds or deletes at least one server from theserver group based on a number of the frequency count. In exemplaryembodiment, there can be a preconfigured frequency count threshold inthe server group. The updated number of the frequency count of each ofthe one or more matching servers in the server can be compared with thepreconfigured frequency count threshold. As an example, appliance 108can determine to add a server into a server group when the server'sfrequency count is equal to or higher than the preconfigured frequencycount threshold. Appliance 108 can also add a server into a server groupwhen an SSL session connection to the server is established within apreconfigured time period, e.g., 0.5 second, given that SSL sessioninformation of the SSL session connection to the server has not beencached. Appliance 108 can also determine to delete a server from aserver group when the server's frequency count is less than thepreconfigured frequency count threshold.

When the client device sends a secure session connection request to eachof the sub-servers, appliance 108 can determine a list of server namesin multiple server groups by accumulating all new SSL connections madeby a client device within a pre-configured time period (e.g., 0.5second). Appliance 108 can form multiple server groups of server namesthat are formed based on the SSL connections formed by a particularclient device to load a web page or a set of web pages. While formingthe multiple server group, appliance 108 does not count the SSLconnection whose session details have been already cached.

FIG. 9 is an exemplary data structure providing a server group for aclient device. Server group for a client device 910 comprises aplurality of server group identifiers (IDs), e.g., 920A and 920B. Eachof the plurality of server group IDs, e.g., 920A and 920B comprises ahead server name 930A, frequency count of the head server name 931A,list of sub-server names 940A, frequency count of each of the sub-servernames 942A-942C, session-related parameter 950A, and timeout 960A. Eachof sub-server names comprises a plurality of server names 941A-941C andcorresponding frequency counts 942A-942C to each of the plurality ofserver names 941A-941C. Session-related parameter 950A can comprisesession information such as session identifier 951A and session ticket952. If session information of session identifier 951A can comprisesession identifier, session ID length, chosen ciphersuite, chosencompression, start time, max fragment length, the master key and otherrelated flags and details. If session information of session ticket 952can comprise session ticket, session ticket length, and session ticketlifetime. Timeout 960A indicates a valid time period that the servergroup ID 920A becomes valid. After expiry of the timeout 960A value, theserver group ID 920A becomes obsolete and/or is deleted from the datastructure. Server Group ID 920B has substantially similar server groupparameter information compared with those of Server Group ID 920A.

In the foregoing specification, embodiments have been described withreference to numerous specific details that can vary from implementationto implementation. Certain adaptations and modifications of thedescribed embodiments can be made. Other embodiments can be apparent tothose skilled in the art from consideration of the specification andpractice of the embodiments disclosed herein. It is intended that thespecification and examples be considered as exemplary only. It is alsointended that the sequence of steps shown in figures are only forillustrative purposes and are not intended to be limited to anyparticular sequence of steps. As such, those skilled in the art canappreciate that these steps can be performed in a different order whileimplementing the same method.

That which is claimed:
 1. An appliance of pre-establishing Secure SocketLayer (SSL) session connections for SSL connection establishment, theappliance comprising: a secure session pre-handshake establishmentmodule configured to: facilitate a secure session connection requestbetween an appliance and a server associated with a website, with thesecure session connection request including a name of the serverassociated with the website, wherein the facilitation causes theappliance to receive session information; reuse at least one session toone or more servers listed in a server group if the session informationcorresponding to the secure session connection request has been cached;and form secure session connections between the appliance and serverslisted in the server group if the session information corresponding tothe secure session connection request has not been cached topre-establish one or more SSL connections so that when one or more SSLconnection requests are received, the one or more pre-established SSLconnections can be used without performing full SSL handshakeprocedures.
 2. The appliance of claim 1, wherein the secure sessionpre-handshake establishment module is further configured to identify theserver group based on information of the server associated with thewebsite in the secure session connection request.
 3. The appliance ofclaim 1, wherein the names of the servers listed in the server groupcomprise a head server name and a plurality of sub-servers names, a headserver representing at least one webpage and comprising a plurality ofobjects provided by the plurality of sub-servers to load completely theat least one webpage.
 4. The appliance of claim 3, wherein the securesession pre-handshake establishment module is further configured todetermine whether there is a matching server among the head server nameand the plurality of sub-servers names in the server group, the matchingserver matching to the server associated with the website.
 5. Theappliance of claim 4, wherein the secure session pre-handshakeestablishment module is further configured to increase a frequency countof the matching server based on the determination that there is amatching server.
 6. The appliance of claim 1, wherein the sessioninformation comprises at least one of session identifier and sessionticket information.
 7. The appliance of claim 6, wherein the sessioninformation is acquired based on a SSL/Transport Layer Security (TLS)full handshake protocol.
 8. The appliance of claim 1, wherein the securesession pre-handshake establishment module is further configured to:accumulate the session connection request and subsequent sessionconnection requests for a predetermined time period, based on thedetermination that session information corresponding to the sessionconnection request and the subsequent session connection requests hasnot been cached; determine whether there are one or more matchingservers in the server group matching to the session connection requestand the subsequent session connection requests; and update a frequencycount of each of the one or more matching servers based on thedetermination that there are the one or more matching servers.
 9. Theappliance of claim 8, wherein the secure session pre-handshakeestablishment module is further configured to add or delete at least oneserver from the server group based on a number of the frequency count.10. The appliance of claim 1, wherein the secure session pre-handshakeestablishment module is further configured to: accumulate SSLconnections made by a client device for a predetermined time period; anddetermine a list of one or more server names belonging to the servergroup based on the accumulated SSL connections.
 11. A method ofpre-establishing Secure Socket Layer (SSL) session connections for SSLconnection establishment, the method comprising: facilitating a securesession connection request between an appliance and a server associatedwith a website, with the secure session connection request including aname of the server associated with the website, wherein the facilitationcauses the appliance to receive session information; reusing at leastone session to one or more servers listed in a server group if thesession information corresponding to the secure session connectionrequest has been cached; and forming secure session connections betweenthe appliance and servers listed in the server group if the sessioninformation corresponding to the secure session connection request hasnot been cached to pre-establish one or more SSL connections so thatwhen one or more SSL connection requests are received, the one or morepre-established SSL connections can be used without performing full SSLhandshake procedures.
 12. The method of claim 11, further comprisingidentifying the server group based on information of the serverassociated with the website in the secure session connection request.13. The method of claim 11, wherein the names of the servers listed inthe server group comprise a head server name and a plurality ofsub-servers names, a head server representing at least one webpage andcomprising a plurality of objects provided by the plurality ofsub-servers to load completely the at least one webpage.
 14. The methodof claim 13, further comprising determining whether there is a matchingserver among the head server name and the plurality of sub-servers namesin the server group, the matching server matching to the serverassociated with the website.
 15. The method of claim 14, furthercomprising increasing a frequency count of the matching server based onthe determination that there is a matching server.
 16. The method ofclaim 11, wherein the session information comprises at least one ofsession identifier and session ticket information, and is acquired basedon a SSL/Transport Layer Security (TLS) full handshake protocol.
 17. Themethod of claim 11, further comprising: accumulating the sessionconnection request and subsequent session connection requests for apredetermined time period, based on the determination that sessioninformation corresponding to the session connection request and thesubsequent session connection requests has not been cached; determiningwhether there are one or more matching servers in the server groupmatching to the session connection request and the subsequent sessionconnection requests; and updating a frequency count of each of the oneor more matching servers based on the determination that there are theone or more matching servers.
 18. The method of claim 17, wherein thesecure session pre-handshake establishment module is further configuredto add or delete at least one server from the server group based on anumber of the frequency count.
 19. The method of claim 11, wherein thesecure session pre-handshake establishment module is further configuredto: accumulate SSL connections made by a client device for apredetermined time period; and determine a list of one or more servernames belonging to the server group based on the accumulated SSLconnections.
 20. A non-transitory computer readable storage medium thatstores a set of instructions that are executable by at least oneprocessor of an appliance to cause the appliance to perform a method ofpre-establishing Secure Socket Layer (SSL) session connections for SSLconnection establishment, the method comprising: facilitating a securesession connection request between an appliance and a server associatedwith a website, with the secure session connection request including aname of the server associated with the website, wherein the facilitationcauses the appliance to receive session information; reusing at leastone session to one or more servers listed in a server group if thesession information corresponding to the secure session connectionrequest has been cached; and forming secure session connections betweenthe appliance and servers listed in the server group if the sessioninformation corresponding to the secure session connection request hasnot been cached to pre-establish one or more SSL connections so thatwhen one or more SSL connection requests are received, the one or morepre-established SSL connections can be used without performing full SSLhandshake procedures.